home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 359 < prev    next >
Encoding:
Text File  |  1996-08-06  |  2.6 KB  |  67 lines

  1. Path: engnews1.Eng.Sun.COM!taumet!clamage
  2. From: "Eugene Radchenko" <eugene@qsar.chem.msu.su>
  3. Newsgroups: comp.std.c++
  4. Subject: Anyone considered inheritable friendship?
  5. Date: 12 Feb 1996 16:20:53 GMT
  6. Organization: Lab. of Org.Synth., MSU
  7. Approved: clamage@eng.sun.com (comp.std.c++)
  8. Message-ID: <AFVop7nqs7@qsar.chem.msu.su>
  9. NNTP-Posting-Host: taumet.eng.sun.com
  10. Content-Type: text
  11. X-Mailer: dMail [Demos Mail for DOS v1.23]
  12. Content-Length: 1909
  13. X-Lines: 46
  14. Originator: clamage@taumet
  15.  
  16. Hi people!
  17. Has anyone proposed/considered the inheritable friendship in addition to
  18. the current one? Suppose the following design (non-template version for
  19. brevity):
  20.  
  21.   class Actor {   //performs some actions
  22.    public:
  23.     //define type X here
  24.     class LittleAction {        //performs some elementary action on X
  25.      public:
  26.       virtual void DoIt(X *x);
  27.       virtual ~LittleAction();
  28.     };
  29.    protected:
  30.     LittleAction *doer;
  31.     Actor(LittleAction *the_doer);
  32.     void Perform(vector<X> &vec);
  33.     friend class LittleAction;
  34.     //some protected data - e.g. some cached procesed 'vec' - needed by
  35.     //    LittleAction
  36.   };
  37.  
  38. Here LittleAction defines abstract interface. We can implement it
  39. differently and pass derived classes to Actor constructor. Actor and
  40. LittleAction hierarchies must work together, LittleAction accessing some
  41. private Actor data (which should not be accessed by other classes).
  42. Everything is OK unless we really use OO design and derive something from
  43. LittleAction - and oops! private data is inaccessible.
  44. I think we should allow inheritable friendship (probably in addition to
  45. current non-inheritable one). Anyway, we are not creating the Pentagon
  46. security system and thus should not be much afraid of deriving Spy from
  47. TrustedUser. Especially considering that otherwise all ends in making this
  48. data public (that's the problem with totalitarism - too tight a regime gets
  49. overthrown).
  50.  
  51.          Bye-Bye                          Genie
  52.  
  53.  
  54. --
  55. -----------------------------------------------------------------------
  56. Eugene V. Radchenko              Research associate, Computer Chemistry
  57. E-mail: eugene@qsar.chem.msu.su                   Fax: +7-(095)939-0290 
  58. Ordinary mail:     Chair of Organic Chemistry, Department of Chemistry,
  59.                          Moscow State University, 119899 Moscow, Russia
  60. ## The careful application of terror is also a form of communication ##
  61.  
  62.  
  63. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  64.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy is
  65.   summarized in http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
  66. ]
  67.